home *** CD-ROM | disk | FTP | other *** search
/ Turnbull China Bikeride / Turnbull China Bikeride - Disc 2.iso / BARNET / ARMLINUX / MAIL / 9701 / 000016_owner-linux-arm…r.rutgers.edu _Wed Jan 22 02:43:06 1997.msg < prev    next >
Internet Message Format  |  1998-01-25  |  7KB
  1. Return-Path: <owner-linux-arm-outgoing@vger.rutgers.edu>
  2. Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id CAA31623 for <willy@odie.fluff.org>; Wed, 22 Jan 1997 02:43:05 GMT
  3. Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <66249-19574>; Wed, 22 Jan 1997 04:41:57 +0200
  4. Received: by vger.rutgers.edu id <213468-2093>; Tue, 21 Jan 1997 21:29:53 -0500
  5. Date:     Wed, 22 Jan 1997 01:19:04 +0000 (GMT)
  6. From: Philip Blundell <pjb27@cam.ac.uk>
  7. X-Sender: pjb27@hammer.thor.cam.ac.uk
  8. To: linux-arm@vger.rutgers.edu
  9. Subject: Re: Arm Linux (fwd)
  10. Message-ID: <Pine.SOL.3.95.970122011842.26176A-100000@hammer.thor.cam.ac.uk>
  11. MIME-Version: 1.0
  12. Content-Type: TEXT/PLAIN; charset=US-ASCII
  13. Sender: owner-linux-arm@vger.rutgers.edu
  14. Precedence: bulk
  15. Status: RO
  16.  
  17. This is from Russell.
  18.  
  19. Philip Blundell writes:
  20. > 1. Kernel stuff
  21. >     - ARM6 support.  This ought not to be very difficult, given that
  22. >       we have ARM3 and StrongARM already (and a good fraction of the
  23. >       ARM6 stuff is in there anyway).  There are plenty of people with 
  24. >       either RiscPCs or other ARM6-based hardware who would like to
  25. >       run Linux.
  26.  
  27. It should not very difficult - I have been redesigning the processor support
  28. in ARM Linux, and now have it done the correct way ;)
  29.  
  30. A single Linux kernel should now be able to run on a RiscPC with
  31. ARM610/ARM710/SA110 processors.  This appears to have temporarly broken the
  32. A5K and ARC code, and is under investigation when I have time.
  33.  
  34. I have been borrowing someones ARM710 card, and I know that Linux now boots
  35. (I allow it to run 'til the end of the kernel initialisation only).  The data
  36. abort handler code needs to be coded though (I don't have any information on
  37. this though), and some way of handling the IMPlementation specific bit in the
  38. page tables (= Updatable on the ARM610).  The ARM610 port I believe is just
  39. another case of the above - the ARM610 and ARM710 I believe are very much
  40. alike.
  41.  
  42. >     - Merge with Linus' source tree.  I think work is ongoing by
  43. >       Russell on this, and the major obstacle at the moment is
  44. >       probably Linus' lack of spare time.
  45.  
  46. I have sorted out the memory management level code, however, I have to upload
  47. a new set of patches (sometime) for Alan to look into).
  48.  
  49. > 2. General user-space stuff
  50. >     - X.  The Xserver for Archimedes hardware isn't really rocket
  51. >       science, since VIDC just gives you a flat framebuffer.  At the
  52. >       moment I think we only have quite an old version, and it would
  53. >       be nice to have the latest XFree86 ported (they really ought to
  54. >       think about changing the name eventually...).
  55.  
  56. The ARM Linux X source is not really based on XF86, except for setting up
  57. the keyboard and switching VTs on startup.  My X port as it stands does not
  58. require XF86 in any way, and I believe that XF86 will only make it larger
  59. for older machines, and therefore slower due to swapping.  This is the main
  60. problem on older machines.  RiscPC's, X appears to fly.
  61.  
  62. There is one improvement that I have planned for it, but I believe that it
  63. may cause more hastles than it is worth - allowing the X server to store
  64. the current key mappings (normally read out of the kernel) in a file.  This
  65. would mean that it should startup quicker than it currently does.
  66.  
  67. Oh - I am currenly seeing quite a few applications where the performance is
  68. severely reduced - perl for instance.  Perl appears to take ages to do
  69. anything meaningful.
  70.  
  71. >     - Debian.  Bruce Perens has shown some interest in having a Debian
  72. >       port for the ARM, and it seems like a good idea. 
  73.  
  74. Indeed.  This would be a great help - I can then concentrate solely on the
  75. kernel aspects (and maybe a few Acorn specific user level bits), rather than
  76. the whole project.
  77.  
  78. > 3. Tools and stuff.
  79. >     - ELF.  Linux is moving to ELF, and we don't want to be left
  80. >       behind.  ELF is important for shared libraries, especially...
  81.  
  82. I'd prefer to hold off on this until a standard appears.  The reason is that
  83. it requires registration, and there are some complex issues that have to be
  84. addressed.  I do have some tools that will read ELF arm in a very minor way,
  85. but it would be totally incorrect to create our own standard until one appears
  86. from ARM Ltd.
  87.  
  88. The reason for this is that if we implement our own, and a standard does appear,
  89. then there will be major incompatabilities in the library and object files.
  90.  
  91. >     - glibc, or libc.so.6, is the new Linux shared library.  It needs
  92. >       to be ported to the ARM.
  93.  
  94. This can be done after we have ELF support (since the latest libc versions are
  95. ELF only).
  96.  
  97. Also, the 2.1.x kernels come into this category.  The 2.1.x kernels have an
  98. altered memory management checking system (it no longer verifies addresses
  99. before using them [will this cause problems on old hardware?], instead they
  100. build up tables of possible faulting instructions.  This will be extremely
  101. difficult for the ARM - we have an unrolled user memcpy routines in the kernel
  102. == loads of different addresses for faulting instructions, and the problem of
  103. how to generate the tables without ELF).
  104.  
  105. So which great person decided to go all out for ELF?  Is he mad?
  106.  
  107. ELF will cause fundamental problems on the ARM3 machines - ELF appears to
  108. require a physical page to be mapped in twice, which is absolutely impossible
  109. on the ARM3 and older.  On the StrongARM, it may be possible, but it'll mean
  110. being careful with the caches.  It may cause cache consistency problems on the
  111. ARM6/ARM7 though since they use a combined data & instruction cache.
  112.  
  113. > 4. Weird stuff.
  114. >     - Some sort of emulator to allow RISC OS binaries to run might be
  115. >       a fun thing to have.
  116.  
  117. I think that this may be more of a disadvantage than an advantage.  There
  118. will obviously be several SWI's that just cannot be implemented - OS_EnterOS,
  119. OS_Memory, OS_SetMemMapEntries, OS_IntOff etc.  I believe that basic may
  120. require at least OS_EnterOS, but that may be wrong.
  121.    _____
  122.   |_____| ------------------------------------------------- ---+---+-
  123.   |   |       Russell King      rmk92@ecs.soton.ac.uk         --- ---
  124.   | | | | http://whirligig.ecs.soton.ac.uk/~rmk92/home.html  /  /  |
  125.   | +-+-+                                                     --- -+-
  126.   /   |               THE developer of ARM Linux              |+| /|\
  127.  /  | | |      *  who wishes that he was in Hong Kong  *      ---  |
  128.     +-+-+ -------------------------------------------------  /\\\  |